Subject: Final Draft of Requirements - I hope

From: "Hildebrand, Jeff" <[email-masked]>
Date: Thu, 02 Jun 94 17:29:00 PDT

I have talked to each of you concerning the ADC requirements and
have received both approval and several comments.  This document
combines all the comments into a final document.  I assume we
have consensus on what the requirements are.  If you have any
concerns please voice them in the next few days.  The next step
will be to build the architecture.
Regards,
Jeff

 ---------------------------------------------------------------

Requirements for Automatic Data Conversion
ADC SIG June 3,1994

Problem Statement

Each system represents basic data types, such as characters or integers,
in ways specific to that system.  For example, character data may be
represented using an ASCII or EBCDIC encoding; integer data may be
represented using a big or little endian encoding.  An executing program
manipulates its data under the presumption that it is represented using
the local system's data representation, the local syntax.

For a distributed application that entails communicating programs
executing on systems with different local syntax's, the resulting
heterogeneous execution environment presents a challenge when the
programs exchange data.  Currently CPI-C provides limited support for
this environment, allowing programs to call routines that convert
character data to and from a fixed data representation (EBCDIC).  The
additional requirement is for automatic data conversion, the ability for
programs to exchange data in any high level construct, such as
array and record data types, and have the meaning of that data preserved
automatically.  A program should not have to know the programming
 language of the partner program or data representation of the
partner system.  The meaning of the data is preserved if, for example,
when a program sends the character "A" and integer "1" to a partner
program, the partner program receives the character "A" and integer "1".

Data Mapping

Some programs require additional data manipulation during data transfer
beyond what can be handled automatically by the systems.

  Two programs manipulate and exchange the same data but for the
  convenience of each, embed the data differently in
  different data structures.  Each program should be able
  to send and receive the data structures known to itself, with the
  mapping between data structures handled by the systems using
  user-provided mapping routines.

  A server connects to many clients and supports multiple application
  systems.  As the systems grow and clients are added, some clients
  require specialized transaction fields that are of no
  benefit to other clients.  While the server and some clients
  must be modified to send and receive the additional fields,
  currently all clients must update their transaction formats
  simultaneously to accommodate these small
  changes.  The cost of these changes adds up
  quickly.  The server requires a user-written mapping routine
  that can modify the data stream so that old systems can
  continue using the old format.

The data mapping requirement is to allow programs to specify that the
data being exchanged with a partner program be translated by
user-provided mapping routines.

Summary

The problem statement yields two high level concepts that the
requirements below must support.  An ADC solution must:

1. Allow a program to exchange data with its partner program and preserve
    the meaning of the data.

2.  Allow a partner program to compensate for semantic differences in the
     application data it sends and/or receives, as the semantics are defined 
by the
     partner program and when the semantic differences are known.

Requirements:

1. There are no restrictions on the type of data that can
be transferred across the network.

2. Since the OSI/TP CRM makes no distinction between
initialization data and regular data, except when they
are sent, both need to be convertible.

3. Expedited data must be convertible.  It should be noted this is an LU 6.2 
CRM
requirement, the OSI TP CRM does not support expedited data.

4. The user supplied converter* software needs to be able
to be hooked into the CRM below the CPIC layer, and able
to convert the data stream:
     A. Prior to CPIC handing it to the CPIC Transaction
          program upon receipt.
     B. Prior to going out to the partner node upon a
          CPIC transaction program send.

5. The converter software must be separate from the CPIC
transaction program, and reusable by multiple programs.

6. No restrictions are placed on the converter's
functionality.  Any restrictions are the result of a
particular implementor's implementation.

* A converter is a user written software routine that is
called by the system to manipulate user data in a user
specified manner.  One of the recognized uses for a
converter is to apply ASN.1 or other user defined
encoding/decoding to user data.